home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20030409-20031118 / 000255_fdc@sesame.cc.columbia.edu_Thu Sep 4 10:16:18 EDT 2003.msg < prev    next >
Text File  |  2020-01-01  |  3KB  |  79 lines
  1. Article: 14495 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news-not-for-mail
  3. From: fdc@sesame.cc.columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: missing bytes...
  6. Date: 4 Sep 2003 10:16:10 -0400
  7. Organization: Columbia University
  8. Lines: 62
  9. Message-ID: <bj7hfa$1ho$1@sesame.cc.columbia.edu>
  10. References: <cf6cc183.0309031713.73a00933@posting.google.com>
  11. NNTP-Posting-Host: sesame.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1062684971 4299 128.59.59.56 (4 Sep 2003 14:16:11 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 4 Sep 2003 14:16:11 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14495
  16.  
  17. In article <cf6cc183.0309031713.73a00933@posting.google.com>,
  18. icurmt <icurmtdude@yahoo.com> wrote:
  19. : After no luck with this issue, I thought of posting it here.. Heres
  20. : what I am trying to do..
  21. : 
  22. : I am sending out commands out of a file through serial port to my
  23. : application which returns me the response accordingly in return..
  24. : 
  25. : <code snippet...> 
  26. : ..
  27. : ...
  28. : transmit /binary /noecho /nowait <commandsfile>
  29. : input 1 -1
  30. : .output := \fhexify(\v(input))
  31. : echo \m(output)
  32. : ...
  33. : fopen /write \%c <outputfile>
  34. : ..
  35. : fwrite /line \%c \m(output)
  36. : ..
  37. : fclose \%c
  38. : 
  39. : </end>
  40. : 
  41. : The script works fine. The response as under is outputted to the
  42. : 'outputfile'. Now when I echo the response I get
  43. : 
  44. : 16 06 14 34 47 12 01 87 
  45. : instead of 
  46. : 16 06 14 34 47 12 00 01 87 00 00 00
  47. : 
  48. : Note the difference after the 6th byte. The 7th and 8th byte which is
  49. : 00 01 shows up as 01 and 10th, 11th and 12th bytes do now show up at
  50. : all. However I have had success getting bytes in the order such as
  51. : below and echoing this command works fine.
  52. : 16 06 14 34 46 11 00 00 BB 10 00 00 
  53. : 
  54. C-Kermit and K95 written in C, in which strings are NUL-terminated.
  55. Thus it is virtually impossible for it to deal with strings that contain
  56. NUL characters -- we would not be able to use C library calls or Unix
  57. system services, all of which require strings to be in this format.
  58.  
  59. This applies also the INPUT buffer.  \v(input) is a string, hence by
  60. definition NUL-terminated.  Realizing that it is common to receive NUL
  61. characters on a communication connection as padding and/or part of the
  62. Telnet NVT data stream, the INPUT command discards NULs so the \v(input)
  63. value will not be truncated the first time a NUL arrives.
  64.  
  65. The only way to deal with NUL characters is on a per-character basis.
  66. If you want to read a series of characters from the connection that can
  67. include NULs, you have to do it using INPUT with no target text. Example:
  68.  
  69.   while (some condition) {
  70.       input 1
  71.       if fail (do something)
  72.       fwrite /char \%c \v(inchar)
  73.   }
  74.  
  75. This works because when \v(inchar) is NUL, that's equivalent to FWRITE /CHAR
  76. having no text argument at all, in which case it writes a NUL character.
  77.  
  78. - Frank
  79.